Many application programs can benefit from the ability to animate the objects within them (e.g., to change the value of an object property over time). Such programs may include, for example, applications where the programmer specifies how the objects are animated and applications that allow an animation designer to design and playback animations. Such applications are typically visual in nature (e.g., two dimensional (2D) or three dimensional (3D) design applications, games, business and consumer applications with graphics, etc.), but they can also include non-visual application, such as data-generating simulation applications. Animations for these types of applications are usually specified in “key frames” or on a frame-by-frame basis.
For the application programmer, deciding which classes and which properties should be animatable and then adding the animation support code to class and property can be a challenging task. Extending the animation support to objects from third party add-ins to the application presents even more challenges.
As an example, consider a 3D design application that supports user design and playback of animation. Typically, an animation designer uses a design application, developed by a programmer, to select and place objects in an environment. The designer can then introduce animation effects by setting animatable properties of the objects. For example, the designer can specify a change in a position property of an object over time to cause the object to move across the screen in a graphical animation sequence. Example results generated by the design application may include an animation key frame data file, a computer generate imagery (CGI) video, a computer game graphics files, etc.
In an animation design environment, a designer may be working with a set of hundreds of animatable objects, each with hundreds of properties. Unfortunately, the designer may be limited in the objects and properties that have been enabled by the programmer for animation. That is, rather than exhaustively providing animation code for all classes and properties, the programmer typically chooses to enable animation for a subset of classes and properties he or she believes will be of use to the designer. In other words, the programmer attempts to predict in advance which classes will need to support animation and then writes special animation code for each property that can be animated. Too often, however, the programmer's choices do not align perfectly with the animator's needs. For example, a programmer may have chosen to provide an interface to a rotation property, but not to a transparency property, even though the property exists in the object. Thus, even if the animation designer wishes to animate transparency on the object, he or she may be unable to provide that effect.
It should be understood that limits to the programmer-provided animation options are typically pragmatic. For example, if a design application supports a hundred animation classes, each of which can have over a hundred potentially animated properties, enabling each and every class/property combination to be animated is an exhaustive programming task. Furthermore, exhaustive programming of such properties would be considered overkill, as the animator is likely to animate only a very small subset of these properties and classes. Exhaustive programming would also result in a design application that is more difficult to maintain. The challenge presented then is: for which classes and properties should the programmer provide animation code, so as to provide the animation designer with all of the options needed, without programming all properties for animation? In this light, existing approaches do not address this challenge and merely limit the animator's animation options, or at least require the animator to go back to the programmer and request incorporation of the missing functionality in the design application.